home *** CD-ROM | disk | FTP | other *** search
/ Ham Radio 2000 / Ham Radio 2000.iso / ham2000 / packet / praf205e / host_kam.doc < prev    next >
Text File  |  1995-04-01  |  9KB  |  168 lines
  1. Hostmode information on Kantronic TNC
  2.  
  3.   ------------------------------------------------------------------
  4.   : This file describes the HostMode on the  Kantronics TNC.  This :
  5.   : file is issued by LA6GHA, Bob, but unfortunately the author is :
  6.   : unknown. Many thanks to SM7OYP for his help.                   :
  7.   :                                                73's de LA6GHA  :
  8.   ------------------------------------------------------------------
  9.  
  10.  
  11.                     KANTRONICS HOST MODE OPERATION
  12.                    --------------------------------
  13.  
  14. In order to operate in the Host mode with Kantronics TNC, you must first
  15. set the Intface command to Host.  After this accomplished,  it  will  be
  16. necessary to perform a soft reset in order to enter the Host mode.  This
  17. may be accomplished by typing reset at the cmd: prompt.  If you want the
  18. TNC to always operate in the Hostmode, be sure to give the command PERM.
  19. (Unless you have battery-backup).
  20.  
  21. You will also need to set the abaud command to the appropriate baud rate
  22. for your terminal. If the abaud command is not set, the TNC will run its
  23. normal autobaud routine,  looking for an asterisk (*) from the keyboard.
  24. When the asterisk is  entered,  the  TNC  will  then  immediately  enter
  25. Hostmode. While operating Hostmode,  your program must use hardware flow
  26. control  (RTS/CTS).  Software flow control is not possible in Host mode.
  27. In the KAM, Host mode only applies to the packet mode (v 3.05 and lower)
  28.  
  29. COMMUNICATION FORMAT - HOST COMPUTER TO TNC
  30.  
  31. Communication from the Host to the TNC must occur in blocks.  The  block
  32. of data is delimited with a FEND character  ($C0)  at the beginning  and
  33. end.  If the FEND character appears within the block as valid data,  the
  34. Host must replace this character with a special sequence,  consisting of
  35. a FESC  ($DB)  by a  TFEND  ($DC).  One other special  sequence  may  be
  36. required in the event a  FESC  ($DB)  characters is required in the data
  37. field.  This is accomplished by the special sequence  of  a  FESC  ($DB)
  38. followed by a TFESC ($DD).  These special sequences are the same used in
  39. the kiss code, as implemented by Phil Karn, KA9Q.
  40.  
  41. After the opening FEND,  the next character is the command byte and will
  42. indicate the type off command being given to the  TNC.  The  permissible
  43. characters in the command byte are C, D or Q.  For the KAM  only,  there
  44. are some other combinations used for non-packet HF mode operation. These
  45. will be covered later.
  46.  
  47. A "C" command byte indicates a command that the TNC will interpret as if
  48. it were in the command mode.  If the command mode byte is a "D", the TNC
  49. will consider the data as data to be transmitted on the  specified  port
  50. and stream.  The letter "Q" in the command byte will cause  the  TNC  to
  51. exit the Host mode and return to terminal mode.
  52.  
  53. The next byte is the port byte.  This byte must be used with every block
  54. of  type  "D"  to  signify  which  port  (1 or 2)  is  to  be  used  for
  55. transmission of the data.  Type  "C"  blocks must always specify this as
  56. either 1 or 2, but this is only used on those commands that are specific
  57. to a port. This would include the connect and disconnect commands.  When
  58. using KAM,  the VHF port is selected by a port byte of  "1"  and the  HF
  59. port is "2". Single port units use port byte "1".
  60.  
  61. The fourth byte is the stream byte.  This byte determines  which  stream
  62. (A-Z) the TNC will use for the data.  If the stream byte is 0 for a data
  63. packet  (command byte D),  the data will be sent out unproto.  (See  the
  64. section on the KAM HF modes for more information).  For commands that do
  65. not not involve a specific port or stream, the port and stream bytes are
  66. ignored, but must be specified.  In the cases, you should address port 1
  67. stream A.
  68.  
  69. After these four header bytes,  the structure of the block for a command
  70. is exactly the same as if you were entering the  command  from  terminal
  71. mode of the TNC.  If entering data to be transmitted,  simply place  the
  72. data in the following bytes.  Note that commands do not need a  carriage
  73. return included in the data portion of the packet.
  74.  
  75. After the data or command,  terminate the information from the Host with
  76. a FEND ($C0) character.
  77.  
  78.  
  79. KAM HF MODES
  80.  
  81. When operating non-packet modes  (i.e., RTTY, ASCII, AMTOR, or CW)  with
  82. the KAM, a few additional Host to TNC frames are required.  First select
  83. the mode with the standard command structure as described  above  (e.g.,
  84. FEND C2ARTTY 75 FEND).  Data that you  wish  to  transmit to  the  other
  85. station should have command byte "D", port byte "2", and stream byte "0"
  86.  
  87. Special Host frames for these modes are:
  88.  
  89.         FEND T FEND          Enter transmit mode
  90.         FEND E FEND          Enter receive mode when buffer empty
  91.         FEND R FEND          Enter receive mode immediately
  92.         FEND X FEND          Return HF port to packet mode
  93.         FEND CTRL-X FEND     Clear the transmit buffer in KAM HF
  94.  
  95.  
  96. TNC TO HOST COMPUTER
  97.  
  98. Communication from the  TNC  to the Host also occurs in blocks which are
  99. delimited at beginning and end with FEND characters ($C0).
  100.  
  101. After the beginning  FEND,  the next character is  the  status  byte.  A
  102. status byte  "C"  is a response to a command  from  the  Host  with  the
  103. command byte "C".  A status byte of  "D"  indicates that  the  data  was
  104. received on a connected stream  (see the section  below  on  the  KAM HF
  105. operation).  "M" in the status byte means that the data in this block is
  106. the result of the monitor commands.  A status byte of  "S"  is a message
  107. caused by a  change  in  the  link  state.  Such  messages  include  the
  108. ***DISCONNECTED, and FRMR sent.  A special "S" block of data consists of
  109. two FEND characters, the characters S00 and another FEND character. This
  110. indicates that the TNC has performed a  soft  reset,  and  all  existing
  111. connections (if any) are not longer valid. This is equivalent to the TNC
  112. having just been turned on.
  113.  
  114. A data block with the  status  byte  ***connect request.  A  block  with
  115. status byte  "T"  is the result of the trace command.  Port  and  stream
  116. bytes  (defined below)  are valid for "D" and "S" blocks,  but only  the
  117. port byte is valid for "T", "M",and "R" blocks.  The port  byte  follows
  118. the  status  byte,  and  will  contain  the  port  number  the  specific
  119. information is from.  This will be a  "1"  if the  TNC  is  single  port
  120. operation,  or a "1" or "2" if in dual port operation.  When  using  the
  121. KAM,  the VHF port is indicated by a port byte of "1".  The stream  byte
  122. follows the port byte.  The stream byte will be "A"-"Z" for data on  the
  123. connected streams.
  124.  
  125. Data being sent to the  Host  which is not connected data will have  the
  126. stream byte set to "0".  If the TNC returns a "C" status block  with  no
  127. data, this indicates that the command was accepted.  This will occur  on
  128. connect and disconnect  commands.  A "T"  block  from  the  Host  (trace
  129. information) is raw data, and not a hex dump of the received packet. The
  130. kiss transparency  (FESC, FEND, and TFESC)  described  above  is  always
  131. applied to all blocks.
  132.  
  133.  
  134. HF MODE OPERATION
  135.  
  136. When using a non-packet mode on the HF port of the KAM, received HF data
  137. will be sent to the Host with status "D", port byte "2", and stream byte
  138. "0".  Each received character is sent from the  KAM  to the  Host  in  a
  139. separate block.
  140.  
  141. When operating AMTOR mode A,  another KAM to  Host  block  is  possible,
  142. indicating the current status of your station  (IRS or ISS).  The  block
  143. has status byte of "I", port byte "2", and the stream byte indicates IRS
  144. ("0") or ISS ("1").  This block will be sent whenever there is a change.
  145. When operating in the AMTOR mode A (ARQ) the KAM will send a  "S"  block
  146. containing information pertinent to the link.  For  instance,  when  the
  147. link is established, the KAM sends a "S" frame with the message <LINKED>
  148. or <LINKED TO xxxxxx>.  "S" frames  are  also  sent  indicating  a  link
  149. failure,  or anytime the KAM returns to amtor standby.  This  can  occur
  150. when the other station breaks the link, or if the link fails due to poor
  151. propagation.
  152.  
  153. When receiving NAVTEX, the KAM does not send any information to the Host
  154. until it has received a proper  NAVTEX  header  for a  message  that  is
  155. vaild to be printed  (see the NAVTEX section of the operations  manual).
  156. The header will be sent to the Host in a single block. After the closing
  157. NNNN of the message if the number of errors received exceeds the  NAVERR
  158. setting,  an error message will  be  sent  from  the  KAM  to  the  Host
  159. indicating ***too many errors*** and the message number.  This  will  be
  160. sent in a  "D20"  frame and not as a  status  frame.  This  allows  this
  161. message, to be stored in the file, if you are capturing the  HF  channel
  162. to disk.  This message will also be sent if the link  fails  before  the
  163. closing of the current message.
  164.  
  165. <EOT - End Of Text>
  166.  
  167. /EX
  168.